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Introduction 

This  document  defines  and  clarifies  the  meaning  and  use  of  High  Level  Mandatory  Requirements 
(HLMRs)  in  the  genesis  of  major  projects  in  DND.  It  identifies  inputs,  outcomes,  considerations  and 
limitations  of  HLMRs,  and  explains  how  they  are  used  and  the  standards  against  which  they  are 
measured. 

Definition 

High  Level  Mandatory  Requirements  (HLMRs)  describe  a  set  of  capabilities  which  a  project  under 
consideration  must  achieve.  Essentially,  they  define  the  expected  outcomes,  effects  or  services  to  be 
delivered  by  the  project  -  what  the  Force  Employer  wants  the  project  to  deliver.  Failure  to  achieve  or 
deliver  any  one  of  these  requirements  constitutes  project  failure.  These  critical  requirements  are  based 
upon  and  are  consistent  with  the  Force  Employer's  concept  of  how  the  solution  will  likely  be  employed, 
and  must  be  clearly  linked  to  a  capability  gap  (which  may  already  be  extant,  which  may  be  developing 
due  to  a  changing  strategic  environment  or  which  may  be  the  result  of  the  impending  end  of  life  of  an 
existing  system).  HLMRs  must  also  link  to  a  specific  element  of  the  approved  CBP  capability  framework. 

HLMRs  are  required  of  all  projects,  be  they  driven  by  Joint  Force  Development  (top-down)  or  Force 
Generator  initiated  (bottom-up),  and  are  developed  during  the  ID  stage  of  the  prospective  project.  They 
are  critical  to  successful  completion  of  Step  2  of  the  BCA,  which  leads  to  the  Strategic  Context 
Document.  Identification  and  approval  of  the  HLMRs  early  in  the  process  ensures  the  alignment  of  the 
proposal  with  the  current  and  projected  strategic  environments,  strategic  objectives,  and  drivers  for 
change. 

The  value  and  need  for  HLMRs  apply  equally  to  Unforecasted  Operational  Requirements.  A  clear  and 
concise  statement  of  the  HLMRs,  paying  particular  attention  to  the  Capability  Attributes,  should  assist  in 
ensuring  that  UORs  are  processed  as  swiftly  as  possible. 

When  developing  HLMRs,  whether  for  a  top-down  or  bottom-up  project,  it  is  critical  to  consider  and 
include,  where  appropriate,  any  joint  implications  of  the  project,  and  to  develop  HLMRs  to  address 
those  implications. 

HLMRs  must  be  solution  independent,  but  must  also  reflect  a  priori  constraints  placed  on  the 
prospective  project.  These  constraints  may  include  such  limitations  as  time,  budget,  technology,  locale, 
related  projects,  etc,  and  must  be  clearly  identified  in  the  HLMR  document. 

Well  defined  HLMRs  are  critical  to  the  success  of  the  Project,  and  are  the  bedrock  on  which  the 
Statement  of  Operational  Requirements  stands. 

Capability  Measures 

HLMRs  are  expressed  in  terms  of  capabilities,  and  must  include  a  method  of  measuring  the 
effectiveness1  of  that  capability,  along  with  an  explanation  of  the  metrics,  how  they  were  derived,  and 


1  Measures  of  Effectiveness  specify  the  intended  results/effects  and  are  presented  in  the  context  of  the  project  -  the  'what'  of  the  capability  — 
H  and  will  be  found  in  the  CBA. 

Measures  of  Performance  are  used  to  measure  the  required  parameters  of  the  solution,  and  are  non-contextual.  That  is,  they  measure  the 
'how'  of  the  capability,  and  are  found  in  the  SOR. 

Thus,  a  Measure  of  Effectiveness  may  state  that  there  is  a  requirement  to  detect  and  destroy  over-the-horizon  targets  with  a  confidence  level 
of  90%  +/-  5%.,  while  the  associated  Measure  of  Performance  may  state  that  the  equipment  must  have  an  over-the-horizon  radar  system 
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their  significance  to  the  overall  project.  It  is  preferred  that  the  Force  Generator  provide  an  Effectiveness 
Envelope,  including  both  target  (the  ideal)  and  minimum  thresholds  (the  minimum  acceptable) 
measures  of  effectiveness.  The  target  value  for  a  capability  is  applicable  when  a  higher  level  of 
effectiveness  comes  with  a  significant  increase  in  operational  utility,  but  at  higher  cost,  schedule,  and/or 
technology  risk.  Effectiveness  above  the  target  value  does  not  justify  additional  expense  whereas 
effectiveness  below  the  threshold  value  is  neither  operationally  effective  nor  suitable  and  may  not 
provide  any  improvement  over  current  capabilities. 


Advances  in  technology  or  changes  in  the  strategic  environment  may  result  in  changes  to  threshold  and 
target  values  in  future  iterations  of  the  CBA.  As  a  measure's  values  change  (as  a  result  of  staff 
discussions,  or  as  part  of  the  CORA  validation),  superseded  values  must  be  identified  in  current  and 
future  documents  for  reference  purposes. 


The  use  of  an  Effectiveness  Envelope,  rather  than  a  single  measure  of  Effectiveness,  is  preferred  as  it 
provides  for  a  trade  space  for  DCB  members  at  the  Options  Analysis  stage.  For  Example: 

The  Force  Employer  has  determined  that,  in  order  to  support  a  Naval  Task  Group  of  up  to  five 
CPFs  and  one  DDG,  without  negatively  impacting  the  operational  capability  of  the  NTG,  the 
Vessel  must  have: 


Capability 

Minimum 

Requirement 

Target 

Requirement 

Maximum  Sustained  Speed 

20  kts 

27  kts 

Aviation 

Number  of 
Flelicopters 

2 

3 

Flight  Deck  Spots 

1 

2 

A  properly  defined  set  of  HLMRs  could  be  depicted  as  shown  below: 


CN 


Excessive 

Options 


Trade  Space 


Unacceptable 

Options 


Ml  M2  M3  Etc 
High  Level  Mandatory  Requirements 
Criteria 

Figure  A  -  HLMR  Environment 


coupled  to  a  weapons  system,  capable  of  simultaneously  detecting  and  engaging  at  least  five  and  as  many  as  ten  discrete  moving  or  still 
targets. 
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Typical  HLMRs  for  a  weapon  system,  for  example,  might  include  some  or  all  of  the  following  HLMRs: 


•  Lethality.  The  ability  of  the  system  to  detect,  target,  engage  and  destroy  threats.  With  respect  to 
the  CBP  process,  this  is  considered  in  conjunction  with  threat  types  and  the  levels  of  precision/low- 
yield  weaponry  required  to  minimize  collateral  damage  when  required. 

•  Survivability.  The  ability  to  sustain  operations  within  the  mission  operational  area.  This  considers 
opponent's  capabilities  and  environmental  threats  to  a  force  element  and  its  ability  to  withstand 
them. 

•  Reach.  The  ability  of  a  force  element  to  operate  autonomously  or  deliver  effect  at  distance. 

•  Persistence.  The  operational  endurance  of  a  force  element. 

•  Responsiveness.  The  ability  to  be  effective  when  and  where  required.  This  includes  the  agility  of 
force  element  to  change  tasks  (tempo)  and  re-orientate  in  mid-operation  (synchronization). 

•  Interoperability.  This  describes  a  force  element's  ability  to  operate  and  share  information.  In 
context  of  a  mission  this  could  include  other  CAF  force  elements  and  headquarters,  other 
governmental  departments  and  allied  forces. 

•  Awareness.  The  ability  to  gather,  fuse  and  display  information.  Within  context  of  the  mission  this 
information  could  be  military-specific  information  or  environmental  type  data. 


Each  HLMR  must  have  the  following  attributes: 


Attribute 

Description 

Clear  and  Concise 

The  language  and  structure  must  be  such  that  the  meaning  will  be  interpreted  the 
same  way  by  all  parties,  especially  including  those  who  will  work  with  the 
requirement  at  some  later  date. 

Feasible 

A  realisable  solution  must  be  possible  within  any  natural  physical  constraints  and 
the  expected  financial  and  schedule  constraints  of  the  acquisition. 

Solution 

Independent 

The  requirements  must  state  what  the  expected  outcome  must  be,  rather  than  how 
to  achieve  that  outcome. 

Unambiguous 

There  must  be  only  one  meaning  or  interpretation  which  can  reasonably  be  drawn 
from  the  definition,  and  qualitative  or  subjective  words  or  descriptions  must  be 
avoided. 

Singular 

Each  requirement  must  capture  a  single  concept  which  cannot  be  subdivided  into 
two  or  more  separate  requirements. 

Verifiable 

There  must  be  a  feasible  and  objective  method  to  verify  the  conformance  of  the 
solution  with  the  requirement. 

Standardised 

Terminology 

The  requirement  must  use  the  same  (standardised)  terminology  as  the  Concept  of 
Operational  Employment  for  the  capability  or  the  terminology  used  in  the  relevant 
scenario  analysis  conducted  under  CBP. 

Complete 

The  requirements  must  address  all  reasonable  and  probable  scenarios. 

Traceable 

Each  requirement  must  be  traceable  to  the  specific  CFDS  mission(s)  and  Capability 
Framework  elements  to  which  it  applies,  including  the  appropriate  Tier  3  activity. 
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Measurable 


The  requirement  must  include  a  method  to  measure  the  Effectiveness  / 
Effectiveness  Envelope.  Measures  of  Effectiveness  should  be  a  single  effectiveness 
measure  derived  from  CORA  analyses  or  other  approved  studies.  Effectiveness 
Envelopes  define  threshold  (minimum  viable)  and  target  (ideal)  levels  of 
effectiveness. 


Table  1  -  HLMR  Attributes 


DRDC  CORA  may  be  requested  to  assist  in  the  development  of  the  HLMRs,  particularly  in  ensuring  that 
the  requirements: 

■  Are  reflective  of  applicable  technology  maturity,  timeframe  the  capability  is  required,  and  supported 
by  analysis. 

■  Comply  with  the  standard  format. 

■  Are  internally  consistent  across  all  parts. 

■  Are  complete,  recording  all  of  the  justifiable  needs  of  all  the  identified  users,  and  all  the  unavoidable 
constraints  from  all  identified  users  and  stakeholders. 

■  Are  not  over-engineered. 

■  Are  not  over-prescriptive. 

■  Are  free  of  system  requirements  or  solution  specifications. 

■  Are  well  structured  and  organised. 

■  Are  correctly  understood  by,  and  satisfy  the  needs  of,  its  target  audience. 

■  Do  not  presume  the  solution 

■  Are  truly  mandatory,  in  that  failure  to  achieve  the  requirement  will  jeopardise  the  project  and 
prevent  a  successful  outcome. 

•  Validation  of  the  requirements  against  the  attributes  listed  in  Table  1  above,  and  their  threshold  and 
target  values,  and 

•  Clarity  of  purpose:  Confirmation  that  the  HLMRs  accurately  and  completely  address  the  capability 
gap  relative  to  the  Concept  of  Operational  Employment  and  CBP  scenario  analyses. 

Capability  Attributes 

In  addition  to  HLMRs  specific  to  the  project  being  developed,  all  projects  should  address  the  following 
Capability  Attributes  (CA)  to  the  fullest  extent  possible,  depending  on  the  current  understanding  of  the 
potential  solution. 

Not  all  CAs  will  be  applicable  in  all  cases,  although  they  should  always  be  considered.  If  the  Force 
Generator  is  of  the  opinion  that  the  CA  is  not  applicable  to  the  Project,  a  statement  to  that  effect  should 
be  included,  with  justification: 

•  Force  Protection  (FP).  All  projects  addressing  a  manned  system,  or  any  system  designed  to 
enhance  personnel  survivability,  must  address  the  requirement  for  Force  Protection.  Although  an  FP 
CA  may  include  many  of  the  same  attributes  as  those  that  contribute  to  the  Survivability  CAs,  the 
intent  of  the  FP  CAs  is  to  address  protection  of  the  system  operator  or  other  personnel  rather  than 
protection  of  the  system  itself. 

•  Survivability:  Survivability  CAs  are  applicable  to  all  projects  addressing  a  manned  system,  and  may 
also  be  applicable  to  projects  addressing  an  unmanned  system.  The  intent  of  the  Survivability  CAs 
includes  reducing  a  system's  likelihood  of  being  engaged  by  hostile  fire,  through  attributes  such  as 
speed,  manoeuvrability,  detectability,  and  countermeasures;  reducing  the  system's  vulnerability  if 
hit  by  hostile  fire,  through  attributes  such  as  armour  and  redundancy  of  critical  components;  and 
allowing  the  system  to  survive  and  continue  to  operate  in  a  CBRN  environment,  if  required.  It  may 
also  incorporate  environmental  considerations  such  as  weather,  climate  and  climate  change. 
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•  Sustainment:  Sustainment  CAs  are  applicable  to  all  projects  addressing  potential  capital 
equipment  procurement  or  construction  projects.  The  intent  of  the  Sustainment  CAs  is  to  ensure 
that  sustainment  planning  "upfront"  enables  the  requirements  and  acquisition  communities  to 
provide  a  system  with  optimal  availability  and  reliability  at  an  affordable  cost. 

•  Information  Interoperability:  Information  Interoperability  is  applicable  to  all  projects 
incorporating  automated  information  systems  used  in  the  acquisition,  storage,  manipulation, 
management,  movement,  control,  display,  switching,  interchange,  transmission,  or  reception  of  data 
or  information  regardless  of  classification  or  sensitivity.  The  intent  of  the  Information 
Interoperability  CAs  is  to  ensure  new  IS  fit  into  the  existing  CF  architectures  and  infrastructure  to  the 
maximum  extent  practicable.  Information  Interoperability  CAs  are  not  applicable  to  projects  where 
communication  with  other  systems  is  not  required. 

•  Training:  Training  CAs  are  applicable  to  virtually  all  projects  involving  changes  to  operations, 
systems,  policies,  and  procedures,  or  capital  equipment  procurement.  The  intent  of  the  Training  CAs 
is  to  ensure  that  training  requirements  are  properly  addressed  as  early  on  in  the  process  as 
practicable,  in  parallel  with  the  planning  and  material  development,  and  updated  throughout  the 
program's  lifecycle.  Given  the  status  of  the  planned  project  at  the  time  HLMRs  and  CAs  are  initially 
developed,  knowledge  of  the  solution  may  not  allow  for  the  development  of  Training  CAs. 

•  Energy:  Energy  CAs  are  applicable  to  all  projects  addressing  systems  where  the  provision  of  energy, 
including  fuel  and  electric  power,  to  the  system  impacts  operational  reach,  or  requires  protection  of 
energy  infrastructure  or  energy  resources  in  the  logistics  supply  chain.  The  intent  of  the  Energy  CAs 
is  to  optimise  fuel  and  electric  power  demand  in  capability  solutions  as  it  directly  affects  the  burden 
on  the  force  to  provide  and  protect  critical  energy  supplies.  The  CAs  include  fuel  and  electric  power 
demand  considerations  in  systems,  including  those  for  operating  "off  grid"  for  extended  periods 
when  necessary.  The  Energy  CAs  may  also  include  'green'  considerations,  with  the  intent  of  reducing 
the  CF's  carbon  footprint  and/or  environmental  impact. 


Process 


The  first  step  in  developing  the  FILMRs  is  for  the  Force  Employer's  staff  to  craft  a  Single  Statement  of 
User  Need  (SSUN)  (see  BC  Guidance  para  1.1.2).  The  SSUN  sets  the  scope  for  the  Preliminary  Options 
Analysis  (POA)  and  helps  to  keep  the  POA  correctly  focused.  It  consists  of  a  single  sentence  or  a  short 
paragraph,  capturing  the  fundamental  essence  of  the  user  requirement. 

The  SSUN  should: 

•  Be  short  -  ideally  one  sentence,  never  more  than  a  single  paragraph  of  four  sentences. 

•  Be  focused  -  enough  to  uniquely  characterise  one  capability  gap. 

•  Have  nouns  and  action  verbs  drawn  from  the  relevant  capability  framework  and  any  analyses  that 
identify  the  capability  gap. 

•  Be  unclassified  -  if  possible. 

•  Not  be  so  detailed  that  it  is  likely  to  require  amendment  as  a  consequence  of  trade-off  activity. 

•  Not  be  quantified  -  unless  the  statement  is  meaningless  without  quantification. 

For  example: 

The  user  requires  a  UK,  deep  and  persistent  ISTAR  capability,  providing  timely  collection, 
processing  and  dissemination,  that  is  interoperable  with  joint  and  coalition  forces  and 
which  is  available  to  support  the  full  range  of  military  tasks.2 


LO 


Corbet,  Gerry:  Dabinet:  A  New  Direction  for  ISTAR  (London:  2011)  http://www.consulting-uk.com/attachedfiles/articles/GCorbet- 
DABINETT.pdf  accessed  13  Nov  13 
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The  next  step  is  to  list  all  the  capabilities  of  the  project  that  would  be  required  to  achieve  success  in 
each  CBP  scenario,  along  with  at  least  one  measurable  effectiveness  attribute  and  the  relevant  metrics 
for  each.  The  capabilities  that  are  most  critical  or  essential  to  the  proposed  project  (those  where  failure 
to  achieve  the  minimum  threshold  will  mean  outright  failure  of  the  project)  will  be  designated  as 
HLMRs.  The  next  step  is  to  document  how  these  HLMRs  are  responsive  to  changes  in  the  desired 
mission  outcomes  and  associated  effects. 


Once  this  is  completed,  threshold  and  target  values  should  be  assigned  to  each  HLMR.  Threshold  values 
should  be  based  on  what  is  achievable  given  the  current  state  of  technology.  Target  values  may  be 
defined  based  on  a  goal  for  the  end-state  of  the  project.  During  the  Options  Analysis  stage,  tradeoffs 
may  made  between  the  threshold  and  target  values  to  optimise  the  outcome,  given  the  availability  of 
technology  and  potential  competing  demands  introduced  by  combining  subsystems  into  the  overall 
system.  A  deeper  review  of  trade-offs  at  and  around  threshold  values  may  be  beneficial  to  explore  the 
incremental  value  for  dollar  where  particular  thresholds  are  insensitive  to  small  deviations.  After  the  OA 
stage,  these  trade-off  decisions  are  essentially  completed  and  a  more  precise  determination  of 
acceptable  performance  can  be  stated  in  the  Statement  of  Operational  Requirements. 

Force  Generators  may  add  additional  requirements  where  they  are  essential  for  providing  the  required 
capabilities/outcomes  and  where  the  definition  of  the  requirements  and  the  recommended  threshold 
and  target  values  are  reflective  of  fiscal  constraints  and  applicable  technology  maturity,  and  are 
supported  by  analysis. 

Significant  changes  to  threshold  and  target  values  after  DCB  approval  will  normally  require  revalidation 
by  the  DCB. 

When  selecting  HLMRs,  the  Force  Generator  should  answer  all  the  following  questions  in  the  affirmative 
for  each  nominated  HLMR: 


•  Is  the  requirement  one  of  the  Capability  Attributes  above,  or  is  it  essential  for  providing  the  required 
capabilities? 

•  Does  the  requirement  contribute  to  significant  improvement  in  war  fighting  capabilities,  operational 
effectiveness,  and/or  operational  suitability? 

•  Is  it  achievable? 

•  Is  it  measurable  and  testable? 

•  Are  the  definition  of  the  attribute  and  the  recommended  threshold  and  target  values  reflective  of 
fiscal  constraints,  applicable  technology  maturity,  timeframe  the  capability  is  required,  and 
supported  by  analysis? 

•  Is  the  Force  Generator  willing  to  consider  restructuring  the  program  if  the  HLMR  is  not  met? 

During  development  of  the  HLMRs,  cost  is  not  a  consideration  unless  an  upper  limit  has  been  provided 

as  a  constraint.  Normally,  costs  are  considered  as  part  of  the  Options  Analysis  stage. 


VO 


Page 


CCC  Ltd  1001-1-1 

HLMRs  in  Context 


onstittihg  Lt 


BUSINESS  CASE  ANALYSIS 


STRATEGIC 

CONTEXT 


DEFINING  THE  REQUIREMENT 


Figure  B  -  HLMRs  and  SSUN  in  Context3 


Traceability 

As  discussed  above,  each  HLMR  must  be  traceable  to  the  specific  CFDS  mission(s)  and  Capability 
Framework  elements  to  which  it  applies.  To  do  this,  Force  Generators  must  identify  the  element  of  the 
approved  CBP  capability  framework  to  which  the  FILMR  relates. 

FILMRs  may  be  summarised  in  a  table  such  as  the  following: 


HIGH  LEVEL  MANDATORY  REQUIREMENTS 

TRACEABILITY  MATRIX 

SINGLE  STATEMENT  OF  USER  NEED: 

Serial 

HLMR  Description 

CBP  Capability  Element 

Gap  Description 

As-ls  Source  Document 

Measure 

Effectiveness 

Envelope 

Table  2-  HLMR  Traceability  Matrix 


cf:  TBS:  Business  Case  Guide  (Ottawa:  2009),  p.  10 


